home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19980424-19980901 / 000118_news@newsmaster….columbia.edu _Fri May 22 14:00:10 1998.msg < prev    next >
Internet Message Format  |  1998-08-31  |  8KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id OAA01133
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 22 May 1998 14:00:09 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id OAA05238
  7.     for kermit.misc@watsun; Fri, 22 May 1998 14:00:08 -0400 (EDT)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
  11. Subject: Re: Kermit on the HP48 (Was: One-Way Transfer)
  12. Date: 22 May 1998 18:00:06 GMT
  13. Organization: Columbia University
  14. Lines: 152
  15. Message-ID: <6k4ef6$g6p$1@apakabar.cc.columbia.edu>
  16. References: <35646665.EBB3868B@theriver.com> <wkvhqye9g4.fsf@jhuapl.edu> <6k42pd$a3m$1@apakabar.cc.columbia.edu> <wk67iy1b8j.fsf@jhuapl.edu>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:8771 comp.sys.hp48:81330
  19.  
  20. In article <wk67iy1b8j.fsf@jhuapl.edu>,
  21. Skip Collins  <collibf1@jhuapl.edu> wrote:
  22. : fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  23. : > But we usually find that what works for us fails to work for others, or
  24. : > vice versa.  No doubt because there are many and varied HP-48 models, ROM
  25. : > versions, etc etc.
  26. : 
  27. : I should have noted that I am using an HP48GX with ROM R, the latest.
  28. : 
  29. : >  1. The top serial speed is 9600, right?
  30. : 
  31. : As far as the built-in kermit is concerned this it true. But there are
  32. : user programs that claim to support 19.2k. I have not tried them.
  33. : 
  34. : >  2. Should the flow control setting be NONE or XON/XOFF?  We have
  35. : >     conflicting reports (see above).  Obviously the HP-48 *should* be
  36. : >     exercising some form of flow control, but some reports indicate that
  37. : >     it does not (even if it is set to do so).
  38. : 
  39. : Why is flow control necessary or even desirable given the maximum
  40. : packet size is 94 and the receive buffer is 255?
  41. : 
  42. Theoretically, it would not be necessary.  But I don't know how their
  43. Kermit implementation works internally.  Does it parse incoming packets as
  44. it reads them, or does it read them first and then parse them?  Can anything
  45. else happen during a read?  Garbage collection, etc?
  46.  
  47. : >  3. Is the link transparent to incoming control characters?  Can the
  48. : >     client Kermit program use control-character unprefixing when sending
  49. : >     to the HP-48?  If not, the client program must be told to
  50. : >     SET CONTROL PREFIX ALL prior to sending files to the HP-48.
  51. : 
  52. : Shouldn't control char unprefixing be a negotiated feature?
  53. :
  54. It would seem so, but no.  The reason is that the two parties have no idea
  55. what lies between them, and so there is no way they can negotiate a safe
  56. set of control characters.
  57.  
  58. : If it is not, I can see where this might be the cause of many people's
  59. : problems. Surely it is not the default?
  60. :
  61. Most Kermit programs prefix all control characters by default when sending a
  62. file.  Kermit 95 is the exception, since most Windows 95 users demand "high
  63. performance".  Kermit 95's default is to unprefix a fairly safe subset of
  64. control characters.
  65.  
  66. : I think the physical link is transparent to control characters. But perhaps
  67. : the hp48 kermit software assumes prefixing.
  68. : 
  69. The cardinal rule of any communications protocol is "be conservative in
  70. what you send, be liberal in what you receive".  The HP48 has it backwards.
  71. There is no prohibition in the protocol definition against sending bare
  72. control characters, thus any Kermit receiver should be prepared to get them,
  73. in which case they are treated like any other data character.  Refusing to
  74. accept them is a mistake.  Almost every Kermit implementation, no matter how
  75. old, accepts bare control characters (assuming they get through the physical
  76. link unscathed).  The programmer has to go out of her/his way to prevent
  77. this from working.
  78.  
  79. : >  4. Does the link allow 8-bit data?  If not, the client must be given
  80. : >     the appropriate SET PARITY command.
  81. : 
  82. : Yes, the link allows 8-bit data.
  83. : 
  84. Good...
  85.  
  86. : > The HP-48 does not support long packets; thus the maximum packet length
  87. : > is 94, but this should be negotiated automatically.
  88. : 
  89. : It is negotiated. As far as I can tell, the only "advanced" feature
  90. : supported by the hp48 is a choice of block checking options 1, 2, or 3.
  91. :
  92. : > The HP communication port is half duplex, meaning that data can go in both
  93. : > directions, but only in one direction at a time.  Therefore sliding
  94. : > windows can not be used (this too should be negotiated automatically).
  95. : 
  96. : The serial port is full duplex. The infrared port is only half-duplex
  97. : because of optical feedback.
  98. :
  99. Does this apply to all models?  I got my information about dead periods in
  100. the serial port from an HP engineer, circa 1990.
  101.  
  102. : The hp48 kermit certainly has not implemented sliding windows. There would
  103. : be very little advantage to doing so for most users who only use a short
  104. : cable to connect to a PC.
  105. : 
  106. : > Postings on comp.sys.hp48 indicate that the HP-48 Kermit implementation
  107. : > "parses" incoming text-mode material on the fly, and appends the material
  108. : > from each incoming packet to a "string", resulting in a steadily
  109. : > deteriorating transfer rate, at least up to some point at which the HP-48
  110. : > dumps the string to storage and starts over with a new string.  There's 
  111. : > not much that the Kermit client can do about that.
  112. : 
  113. : This is the biggest problem with hp48 kermit.
  114. : 
  115. Can you help clear this up?  What is the deal?  Text-mode transfers into
  116. the HP-48 are the ones that get progressively slower?  But binary-mode
  117. transfers into the HP-48 are OK?
  118.  
  119. Is it true that incoming text-mode packets are parsed as HP-48 programs?
  120. So this means that only HP-48 programs may be sent in text mode, and any
  121. other text files sent to the HP-48 are likely to be rejected.  One user
  122. reported that any text file containing a "-" character would be rejected
  123. for "Invalid syntax".
  124.  
  125. This means that non-HP-48-program files must be sent to the HP-48 in binary
  126. mode, right?
  127.  
  128. So let's start trying to put together the settings to use with MS-DOS Kermit,
  129. C-Kermit, and Kermit 95 for transferring files with the HP-48:
  130.  
  131.   set modem type direct  ; (Skip this in MS-DOS Kermit)
  132.   set carrier-watch off  ; (Does the HP-48 assert DCD? If so, use ON.)
  133.   set port <whatever>
  134.   set speed 9600         ; (The best the HP-48 can do)
  135.   set flow none          ; (or Xon/Xoff)  
  136.   set parity none        ; (The HP can accept 8-bit data)
  137.   set control prefix all ; (Don't send bare control chars)
  138.   set receive timeout 99 ; (see Note 1 below...)
  139.   set send pause 100     ; (see Note 2 below...)
  140.  
  141. Items such as packet length and window size are negotiated automatically;
  142. there is no need to set them.
  143.  
  144.  1. If it takes the HP-48 a long time acknowledge data packets (e.g. 
  145.     in text mode), tell the file sender to wait a long time for the
  146.     acknowledgement.  (Newer versions of C-Kermit and K95 will adjust
  147.     their timeouts dynamically according to the actual behavior, in
  148.     which case the SET RECEIVE TIMEOUT command is not needed.)
  149.  
  150.  2. The SET SEND PAUSE command is needed if the HP-48's serial port is
  151.     half duplex.  The number (100 milliseconds) might need adjustment.
  152.     I'm sure this is highly dependent on the exact model and ROM version.
  153.  
  154. Finally:
  155.  
  156.   set file type text     ; For HP-48 programs
  157.  
  158. or:
  159.  
  160.   set file type binary   ; For all other forms of data
  161.  
  162. Oh, by the way, another peculiarity I noticed...  If the HP-48 is set up to
  163. be client of a Kermit server, its method for getting directory listings is
  164. rather odd.  Instead of sending a REMOTE DIRECTORY protocol message, it
  165. sends REMOTE HOST DIR/W.  Of course, this won't work unless the server:
  166.  
  167.  a. Is a DOS or Windows or OS/2 system, and:
  168.  
  169.  b. Has HOST ENABLE'd in its Kermit server.
  170.  
  171. - Frank